perf(codegen): inline charCodeAt and stop routing it through the dynamic bitwise helper (#7592) - #7601

Closes the hash-phase half of #7592. #7594 and #7596 took build_out
from 57 s to ~5–6 s; this is the phase that was next-largest behind it.

I re-measured before touching anything, and two of the ticket's three

figures were stale

#7592's phase table was captured before #7594/#7596. Re-running the
instrumented workload on the pinned quiet host at v0.5.1338:

stringify had already been fixed by the GC pacing work — its old number was
GC pause charged to the phase it happened to land in. So there is no
stringify change in this PR: at 267 ms it is 2.5% of the run, and touching
JSON.stringify's shape-template path for that would be risk without a
return. The fnv1a phase was real.

Leaf profile: 85% of the hash phase was FFI, not work

PERRY_DEBUG_SYMBOLS=1 + sample, isolated hash driver over the workload's
own 68 MB output, pinned quiet host:

h = (h ^ s.charCodeAt(i)) | 0 was making four opaque runtime calls per
character over 68 million characters. Every one of those helpers is a
handful of instructions; the cost is the FFI boundary — and an opaque call on
a loop's critical path also blocks LICM, so the loop-invariant receiver unbox
and header loads could never be hoisted out.

Two independent defects

1. charCodeAt was not statically a Number. is_numeric_expr has arms
for locals, class fields, Math.*, typed-array reads and user functions, but
none for a String-method call. So h ^ s.charCodeAt(i) failed
expr/binary.rs's "both operands are statically primitive" test and routed
through js_dynamic_bitxor — the BigInt-aware helper — to compute an integer
xor. Fixed by teaching is_numeric_expr about the String methods that lower
to a raw double.

The admitted set is exactly charCodeAt, indexOf, lastIndexOf, search,
localeCompare — each verified against its lowering in
lower_string_method.rs (all sitofp of an i32 helper, or a helper
documented to return a plain f64). codePointAt is deliberately excluded:
it returns undefined out of range, which is a NaN-box tag, not a number —
claiming it numeric would hand a tagged value straight to an inline fadd.
at/charAt (strings) and startsWith/endsWith/includes (booleans) are
excluded for the same reason. The claim is gated on the receiver taking
codegen's proven-string routing, mirroring lower_call/property_get.rs's
condition exactly, so an any-typed receiver — which may be a user object
with its own charCodeAt — is never claimed.

2. charCodeAt itself had no inline path. Added one: a guard chain that
reproduces exactly what js_string_char_code_at + js_string_index_to_i32
compute, falling back to those same two calls for anything it cannot prove.

• STRING_TAG receiver, handle ≥ 4096 (the runtime's is_valid_string_ptr
  magnitude check);
• 0.0 <= index < 2^31-1 as ordered comparisons — a NaN-boxed index
  (a string, a bool, undefined, a real NaN) fails both and takes the slow
  arm where the full ToIntegerOrInfinity including user valueOf runs.
  This also makes the subsequent fptosi in-range, so it can never be poison;
• utf16_len == byte_len — the runtime's own is_ascii_string predicate.
  Equality implies every byte is one UTF-16 code unit, hence every byte
  < 0x80, so no WTF-8 / lone-surrogate / astral payload can reach the byte
  load (Runtime split()/parseFloat() read past exact-sized slice allocations -> intermittent AV (c0000005) on hot paths #6085's bounded walk still owns those);
• index < utf16_len.

No allocation and no call occur between the receiver re-read and the byte
load, so no collection can move the header underneath the fast path.

No new env knob: it rides PERRY_STATIC_STRING_LOWERING, the same gate the
sibling inline .length fast path uses (already keyed into the object cache
and the repsel knob-isolation harness).

The layout coupling is pinned, not assumed

The fast path reads StringHeader at offsets 0, 4 and 20. Offset 0 is
already an established contract (the inline .length load), but it was
resting on a doc comment. perry-codegen cannot depend on perry-runtime,
so the two sides get a const assertion at the struct definition
(STRING_HEADER_ABI_MATCHES_CODEGEN): reordering, resizing or padding
StringHeader now fails the runtime build, at the definition, instead of
silently miscompiling every .length and charCodeAt in every user program.

Result

Both arms built from one target dir with an identical package set
(-p perry -p perry-runtime-static -p perry-stdlib-static), run interleaved
on the pinned quiet host (perry-macos.local, load 1.5–2.3 throughout).
Output file cmp-identical and the reported hash identical on every row.

Isolated hash driver over the workload's own 68 MB output, 3 reps each,
three interleaved pairs:

11.2x, and the run-to-run spread is under 0.2% on both arms.

Full pipeline, median of 2–3 interleaved pairs after warmup:

Peak RSS is unchanged (−0.1% at 200k, −0.002% at 500k) — this is a codegen
change with no allocation behaviour, so it adds nothing on top of #7594's and
#7596's RSS cost.

build_out is statistically identical across the arms (200k: 2,349 vs
2,351 ms; 500k: 9,127–9,192 vs 8,694–9,224, a ±5% band both sides). The first
500k pair I ran showed 8,461 vs 9,216 and I did not report it as a regression —
re-running showed it was a cold-page-cache first-run outlier on the base arm.

The post-fix leaf profile of the hash driver is a single symbol:

Sort by top of stack, same collapsed (when >= 5):
        perry_fn_fnv_only_ts__fnv1a32  (in fnv_sym_fix)        1530

Every runtime call is gone from the hot path.

The A/B above is at the #7594 base (08940c877), because that is where I
started before #7596 landed. That is the right base for this claim: the hash
phase allocates nothing and never touches the collector, so GC pacing cannot
move it — and indeed #7596 is a build_out change. The branch is rebased on
#7596 and re-measured; absolute post-rebase numbers are in the thread.

Also here

• A test for perf(gc): live-proportional collection budgets at both generations (#7592) #7596's untested third change. scavenge_nursery_cap_effective_bytes
  gained a max(influx_driven, old_gen_reclaimable/2) term with no coverage,
  and the sibling cap_scale_grows_on_heavy_influx_and_shrinks_when_quiet
  only looks like coverage: it asserts against the effective cap in a
  unit-test thread whose old-gen is ~empty, so the proportional term
  contributes 0 and that test stays green with the term deleted. The policy
  is now a pure function of its two inputs and is tested directly.
• The json_pipeline workload's header comment. It carried a v0.5.29
  block claiming process.argv.slice(2) returns garbage, that iterating a
  large JSON.parse result corrupts records above ~200, and that the driver
  therefore runs Perry on the 100-record fixture only. perf: json_pipeline at 500k records is 97.6x bun (60.4s vs 618ms) while the same workload at 100 records BEATS bun — a scaling cliff, not a constant factor #7592 disproved the
  second and third; I probed the first and it is also false. Deleted rather
  than left to misdirect the next reader.

Validation

• cargo test -p perry-runtime --lib --no-fail-fast — 1847 passed, 0 failed.
• cargo test -p perry-codegen --lib --no-fail-fast — 676 passed, 0 failed.
• New gap test test_gap_7592_char_code_at_inline.ts, byte-identical to the
  Node 26.5.1 oracle. It is deliberately adversarial to the fast path: ASCII
  heap string, SSO receiver, empty string, accented (multi-byte) payload,
  astral surrogate pair, lone surrogate, a full 0–255 binary-string round-trip
  (every byte ≥ 128 makes byte_len > utf16_len, so those must take the slow
  arm), out-of-range on both ends, ±Infinity, NaN, fractional and -0.5
  indices, string/bool/null/undefined/{valueOf} indices, the no-arg form, a
  nullable-string receiver, and the FNV-1a loop itself over each shape.
• Sabotage-verified, five ways. Each mutation was applied, the suite run,
  and the mutation reverted:
  • disable the numeric claim → char_code_at_on_a_string_receiver_is_statically_numeric
    fails, the other two pass;
  • disable the inline path → ..._emits_the_inline_ascii_read fails, the other
    two pass;
  • widen the receiver gate to every receiver → the negative control
    char_code_at_on_an_unproven_receiver_keeps_the_runtime_lowering fails,
    the other two pass;
  • drop the tenured term from the nursery cap →
    nursery_cap_becomes_tenured_proportional_above_the_crossover fails;
  • drop the influx floor → all three nursery-cap tests fail.
    The first pass of the codegen assertions was itself vacuous — they matched
    @js_dynamic_bitxor anywhere in the module, which every module declares.
    They now match call double @js_dynamic_bitxor. The negative control caught
    that: it was passing on the declaration alone.
• The StringHeader ABI assertion is sabotage-verified too — changing
  offset_of!(byte_len) from 4 to 8 fails the runtime build with
  evaluation panicked, and restoring it compiles.
• Gates: raw_handle_debt.py 998/998, addr_class_inventory.py pass,
  class_id_collisions.py pass, check_file_size.sh pass (the inline lowering
  pushed lower_string_method.rs to 2100 lines, so it moved to a sibling
  module lower_string_method/char_code_at.rs), cargo fmt --all -- --check
  clean, cargo clippy on both changed crates introduces no new warning.

CI has a deep backlog, so the above is local validation — that is what this
PR is standing on.

Summary by CodeRabbit

• Performance
  • Improved String.prototype.charCodeAt performance with a faster path for ASCII strings.
  • Enabled more efficient numeric handling for indexOf, lastIndexOf, search, and localeCompare.
• Bug Fixes
  • Preserved correct behavior for non-ASCII strings, coercion, out-of-range indexes, and dynamic values.
  • Added safeguards to detect incompatible string layout changes.
• Documentation
  • Updated benchmark findings to confirm full large-record processing and output compatibility, with performance remaining the primary gap.